The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over telecommunication networks (see 3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329). IMS provides key features to enrich the end-user person-to-person communication experience through the integration and interaction of services. IMS allows new rich person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
FIG. 1 illustrates schematically the architecture for the IMS and its relationship to an IP-Connectivity Access Network (IP-CAN). In the IMS, Call/Session Control Functions (CSCFs) operate as SIP proxies, and interface with other entities such as Border Gateway Control Functions (BGCFs) and Media Resource Function Controllers (MRFCs) amongst others. The 3GPP architecture defines three types of CSCFs: a Proxy CSCF (P-CSCF) is the first point of contact within the IMS for a User Equipment; a Serving CSCF (S-CSCF) provides services to a subscriber; and an Interrogating CSCF (I-CSCF) identifies the correct S-CSCF and forwards to that S-CSCF a request received from a User Equipment via a P-CSCF. In this regard, a User Equipment may be any device, mobile or stationary, enabled to communicate by radio or any other means with the IMS via an IP-CAN, for instance but not limited to e.g. mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, or any type of consumer electronic device, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop, or PC.
Within the IMS service network, Application Servers (ASs) are provided for implementing IMS service functionality. Application Servers provide services to end users in an IMS system, and may be connected either as end-points over the 3GPP defined Ma interface, or “linked in” by an S-CSCF over the 3GPP defined ISC interface. In the latter case, Initial Filter Criteria (IFC) are used by an S-CSCF to determine which Applications Servers should be “linked in” during a SIP Session establishment (or indeed for the purpose of any SIP method, session or non-session related). The IFCs are received by the S-CSCF from an HSS during the IMS registration procedure as part of a user's Subscriber Profile.
3GPP also defines a number of supplementary services that are supported by IMS. For example, the standardized supplementary services supported by IMS include but are not limited to Originating Identification Presentation (OIP), Originating Identification Restriction (OIR), Terminating Identification Presentation (TIP), Terminating Identification Restriction (TIR), Communication Diversion (CDIV), Communication Hold (HOLD), Communication Barring (CB), Message Waiting Indication (MWI), Conference (CONF), Advice Of Charge (AOC), Communication Waiting (CW), Flexible Alerting, Customized Alerting Tones (CAT), and Customized Ringing Signal (CRS). In addition to the standardized supplementary services, the vendor of an IMS Application Server can configure an Application Server so as to implement additional, vendor specific services. An example of such a vendor specific service is the Flexible Communication Distribution service.
The CONFerence (CONF) service enables a user to participate in and control a simultaneous communication involving a number of users. The applicable 3GPP Technical Specifications detail the procedures that allow a user to create and participate in a conference. For example, to create a conference, a user's UE can generate an initial SIP INVITE request and set the request URI (Uniform Resource Identifier) of the INVITE request to a conference factory URI that will cause the INVITE to be routed to a specific conferencing AS. If the conferencing AS determines that it can host a conference for the user (e.g. if the user is authorised/verified), then the conferencing AS will allocate a conference URI as an identifier for the conference, and return this conference URI to the user. In order to invite other user's to join the conference, the UE can then either send a REFER request to the user directly, with the Refer-To header of the REFER request set to a conference URI of the conference, or can send a REFER request to the conferencing AS, with the Refer-To header of the REFER request set to the SIP URI or tel URI of the user who is invited to the conference. As an alternative example, in order to create a conference, a UE can generate a SIP INVITE request that is sent to the conferencing AS using the conference factory URI, and can attach a message body to the request that includes a URI list that identifies the other users that are to be invited to the conference.
Upon receipt of either a REFER request that requests that other users are invited to a conference or an INVITE request that creates a conference and includes a list of other users that are to be invited to the conference, the conferencing AS can invite users to the conference by sending either an INVITE request or a REFER request to the invited user(s), the request including the conference URI of the conference. Following receipt of either an INVITE request or a REFER request from the conferencing AS at the UE of an invited user, the invited user can then decide whether or not to accept the invitation and join the conference. In order to join the conference, the UE of the invited user can then generate and send an INVITE request with the request URI of the INVITE request set to the conference URI received from the conferencing AS in the INVITE request or REFER request.
It has been recognised here that the conventional conference service described above require that all of the users that wish to participate in a conference must do so by contacting the same dedicated conferencing AS, using either a conference factory URI of the conferencing AS or a conference URI allocated to a conference instance by the conferencing AS, and that such a solution therefore suffers from capacity limitations, and does not scale well when implemented in large systems such as in residential or enterprise environments. In particular, the capacity of a single conferencing AS will be limited in terms of the number of simultaneous traffic sessions that can be supported as well as the number of conferences that can be scheduled. Whilst it is possible to circumvent this problem by making use of several different conferencing ASs within a system, with each conferencing AS serving a subset of the users of the system, this means that different users will be assigned different conference factory URIs for use when requesting a conference service.